Problem

A turn running a long tool call dies with:

Cursor run stalled (no events for 60000ms)

That message comes from the anyEvent === true branch of onStall — it's terminal: the run is cancelled and the turn is lost, with no retry.

The stream watchdog re-arms only from push(), which fires for the ten update types mapped in onDelta's switch. Between tool-call-started and tool-call-completed a long shell command, build, or test suite streams nothing at all, so a perfectly healthy run trips the 60s budget. Raising the constant alone doesn't fix it — any fixed ceiling still kills a long-enough tool, while making a genuinely wedged run take longer to surface.

The switch also has no default case, so any update type the plugin doesn't model is dropped and never counts as liveness.

Fix

Two budgets. armWatchdog() picks based on whether any tool call is open:

A tool-phase stall stays terminal but now names the culprit:

Cursor run stalled (no events for 600000ms; tool "shell" still in flight).
Raise OPENCODE_CURSOR_TOOL_STALL_MS (or set 0 to disable) if this legitimately runs longer.

Re-arm on raw SDK activity. armWatchdog() is called for every onDelta update, not just mapped ones, so progress/heartbeat types count as liveness. It runs after the switch so it observes post-mutation openTools state and always selects the correct budget.

Reconcile openTools. Cleared on turn-ended and on a forced resend. Without this, a dropped or differently-keyed completion pins the turn to the 10-minute budget and names a tool that already finished.

Env parsing hardening. Number("abc") is NaN, and NaN <= 0 is false — so the old guard passed and setTimeout(fn, NaN) fired immediately, stalling every turn. Non-finite values now fall back to the default. An empty string still yields 0 (disabled), preserving the existing escape hatch.

Testing

npm run typecheck clean · npm test 367 passed · npm run build succeeds.

10 new tests, including 3 explicit negative controls that prove the positive results come from the fix rather than the harness (e.g. the same timeline minus the intervening update does stall).

Each production change was mutation-tested — reverted individually to confirm a test actually fails:

The 3 pre-existing watchdog tests are unchanged and still pass.

Scope

Deliberately excludes the Cursor SDK log-line leak — #85 covers that, and its approach (routing to client.app.log, plus sidecar coverage) is the better one.

Two suggestions for #85 from investigating the same area:

• test/e2e/transport.e2e.ts:31-35 maps a bare JSON.parse over every stdout line with no try/catch, so one leaked line fails the suite with an opaque parse error instead of a useful assertion. It's the only e2e guard for that bug class.
• Matching on message names (as feat: structured logging for provider diagnostics + Cursor SDK rules/skills logs #85 does) is more robust than matching on the HH:MM:SS.mmm prefix — that timestamp is an SDK option we don't control, and feat: structured logging for provider diagnostics + Cursor SDK rules/skills logs #85's own sample output doesn't show it.

Known limitations

• No absolute per-turn ceiling. Re-arming on any update means a runtime emitting heartbeats while genuinely wedged could re-arm indefinitely. Left out deliberately: there's no evidence Cursor emits unmapped update types today, so a third timeout knob would be speculative. OPENCODE_CURSOR_DEBUG=1 already counts every update type if this ever needs revisiting.
• await runHolder.run?.cancel() in failTerminal is unbounded. Pre-existing, but the tool-phase path makes it more reachable — a wedged run is exactly the case where cancel() may not settle. Worth its own change.
• Not validated against a live agent. No CURSOR_API_KEY was available. The tool-phase-vs-idle-phase diagnosis is inferred from the error string and the reported symptom (a long-running command); the fix covers both phases so either diagnosis is handled, but an end-to-end run with a multi-minute tool would confirm it.